This disclosure relates generally to database recovery, and more specifically, to point in time recovery and rebuilding indexes.
Database recovery has traditionally been utilized to recover data that has been lost from hardware disasters or user errors. For example, data loss may result from media errors, natural disasters that cause data crash, or a user may delete a table by mistake. Various backup mechanisms may be utilized to recover data for different purposes. For example, a full database backup provides a complete archive of a database as it existed at the time a backup operation finished, which may be useful when hardware disasters occur. Another recovery mechanism is a snapshot, which may be utilized when user errors have occurred or for reporting purposes. A snapshot is a read-only image copy of a database as it existed at the time of the snapshot creation. Some of the snapshot data (e.g., database records that have been deleted in a database file) may be written to a backup file (e.g., a sparse file) to store the data for recovery of the data at a later time.
In cases where a snapshot is utilized, database tools may provide a function to recover the database back to a specific time, which is known as “point in time recovery.” The objects recovered may be data (e.g., database records, tables, etc.), indexes, or both. Indexes may be utilized to sort various database records for particular columns in an organized fashion to allow efficient retrieval of the database records, as opposed to performing a full table scan to find the database records. Generally, there are two phases involved in point in time recovery. The RESTORE phase uses a snapshot of the database as a recovery base to replace the current database prior to a desired point in time. A LOGAPPLY phase scans database transaction logs and applies (writes) changes to the snapshot to get to a particular point in time or state of the database that the user desires.